1. Field of the Invention
The present invention relates to a simulation technique using a computer. More particularly, the present invention relates to a system, a method, and a program for software-based simulation of a physical unit such as the engine of an automobile.
2. Description of the Related Art
In the early 20th century, an automobile was made up of an engine as a power source, and mechanical parts including a brake, an accelerator, a steering wheel, a transmission, and a suspension, with little use of electrical mechanisms except for an ignition plug for the engine and headlights.
However, around the 1970s, there arose the need to control the engine efficiently in preparation for air pollution and oil crisis. Thus, an ECU started to be used for engine control. In general, the ECU includes an input interface used, for example, for AD conversion of an input signal from a sensor, a logical operation unit (microcomputer) for processing a digital input signal according to predetermined logic, and an output interface for converting the processing result into an actuator operating signal.
A significant proportion of recent automobiles are now occupied not only by mechanical parts but also by electronic components and software, which range from control systems for the engine and the transmission, an anti-lock braking system (ABS), electronic stability control (ESC), and power steering, to wiper control, and a security monitoring system. The development cost for the latter is said to be 25% or 40% of the total cost, and accounts for 70% in a hybrid car.
Multiple ECUs are arranged to provide electronic control. The ECUs are connected to each other via an in-vehicle network such as a controller area network (CAN). The engine and transmission, which are to be controlled, are wire-connected directly to the respective ECUs.
The ECU is a small computer, and is operated according to an interrupt from a sensor input, for example. Meanwhile, the engine continuously performs mechanical operations. In other words, a computer digital system and a mechanical physical system perform cooperative operations in parallel in a single system as an automobile. Naturally, software supporting those operations has become more and more complicated. Therefore, it is desired to achieve a mechanism not only for verifying the operation of a single ECU but also for verifying the operations of multiple ECUs at the same time.
Meanwhile, actuators driven by an output signal from respective ECUs include an electromagnetic solenoid, a motor, for example. The solenoid is used, for example, for an injector of the engine, shift control of the transmission, brake valve control, and a door lock.
As a conventional technique for testing such devices, there is HILS (Hardware In the Loop Simulation). Particularly, an environment for testing all the ECUs in the automobile is called full-vehicle HILS (Hardware In the Loop Simulation). In the full-vehicle HILS, a test is conducted in a laboratory according to a predetermined scenario by connecting a real ECU to a dedicated hardware device emulating an engine, or a transmission mechanism. The output from the ECU is input to a monitoring computer, and further displayed on a display to allow a person in charge of the test to check if there is any abnormal action while viewing the display.
However, in HILS, the dedicated hardware device is used and the device and the real ECU have to be physically wired. Thus, HILS involves a lot of preparation. Further, when a test is conducted by replacing the ECU with another, the device and the ECU have to be physically reconnected, requiring even more work. Further, because the test uses the real ECU, it takes actual time to conduct the test. Therefore, it takes an immense amount of time to test many scenarios. In addition, the hardware device for emulation of HILS is generally very expensive.
Therefore, a technique using software without using such an expensive emulation hardware device has recently been employed. This technique is called SILS (Software In the Loop Simulation), in which all components to be mounted in the ECU, such as a microcomputer, an I/O circuit, and a control scenario, are configured by using a software simulator. This enables the test to be conducted without the hardware of the ECU.
In the meantime, a simulation system for automobiles includes a continuous system simulator and a discrete system (discrete event) simulator. An example of the continuous system simulator is a simulator for simulating a mechanical part of the engine. An example of the discrete event simulator is a simulator for an ECU operated with pulse timing of the engine rotation to control the timing of fuel injection or ignition.
For simulation of a 4WD, there is a simulator for repeatedly calculating the behavior of the car from the torque distribution to each wheel as an example of the continuous system simulator, and there is a simulator operated with a periodic pulse signal output at every interval of 10 milliseconds to simulate an ECU to determine the torque distribution to each wheel from a sensor input such as the yaw rate of the car as an example of the discrete event simulator.
Since it takes a lot of time to conduct a test along a specific test scenario in such a system, there is a constant demand for improvement in processing speed to reduce the overall time.
Japanese Patent Application Publication No. 2001-290860 aims at providing a hardware/software cooperation simulator, which finds unnecessary synchronization processes between simulators to reduce the number of synchronization processes in order to improve the simulation speed. The simulator includes simulation cooperation means for synchronizing CPU simulation means with peripheral circuit simulation means, and determination means for determining whether to inhibit the synchronization achieved by the simulation cooperation means, wherein the synchronization achieved by the simulation cooperation means is inhibited based on the determination means.
Japanese Patent Application Publication No. 8-227367 aims at obtaining a debugger for increasing a debug speed by using a high-speed simulator in which all system operations but a system operation whose design error is expected are ignored. The debugger includes a bus simulator of a bus for providing a signal corresponding to a bus cycle for mutually connecting each simulator, and means for omitting a bus cycle unnecessary for the simulation, wherein a CPU bus cycle unrelated to the simulation is omitted, or only the schedule of a periodic clock signal is generated without explicitly simulating the clock signal.
Japanese Patent Application Publication No. 2004-30228 discloses a configuration including a CPU simulator, one or more peripheral macro-simulators, and execution of synchronization control processing part for controlling the execution of synchronization therebetween. When a signal input to a terminal based on simulation by the CPU simulator is changed, the peripheral macro-simulator performs simulation based on the terminal signal changed, detects the change in the input terminal signal, registers the changed terminal signal in a terminal signal list 22, and performs simulation on only the registered terminal signal.
Japanese Patent Application Publication No. 2006-65758 discloses a circuit simulation technique in which a second discrete-time model is created by applying a response function to a first discrete-time model created from circuit data, and the edge timing of a clock and the effective signal value of a signal input/output to/from a clock synchronization circuit are calculated using the second discrete-time model to perform simulation.
Although these conventional techniques can help improve the execution speed of a normal simulation system, it is difficult to apply them to a discrete system driven on an event basis such as an ECU emulator.
Therefore, inventors including those of the present application disclose, in the specification of Japanese Patent Application No. 2008-151047, a technique capable of improving the processing speed of a simulator as follows: A physical unit simulator is allowed to speculatively perform high-speed continuous operations under normal conditions. Only when an actual input comes in, a speculative input and the actual input are compared with each other. In response to inconsistency between the inputs, the physical unit simulator is returned to a point closest to the point of the actual input and is allowed to execute a variable step until it reaches the point of the actual input. Upon arrival at the point of the actual input, the simulator gets back to the high-speed continuous operations from the point.